Method of facilitating a synchronized play of content and system thereof

ABSTRACT

In a user&#39;s device, a computerized method for facilitating a synchronized play of content by a user device&#39;s player is provided. The method comprising: receiving a reference position in the content; retrieving a player position in the content; and based on the received reference position and the retrieved player position: determining if the player position is nearly synchronized with the reference position; and if in the negative, applying a synchronization process to reach a calculated sync player position, such that the player position, when reaching the sync player position, is nearly synchronized with the reference position.

TECHNICAL FIELD

The presently disclosed subject matter relates to synchronized play ofcontent, and, more particularly, to synchronized play of content by aplayer of a user device player, or by a plurality of players of userdevices.

BACKGROUND

When a content provider, also to be referred to herein as a serviceprovider, provides content for playing on a user device, the contentprovider would like that this content be played in the best manner interms of user experience. If the content is live content, the contentprovider would like that this content be played as close to the livebroadcast time as possible. If several users wish to view together thesame content, or share either a live content or a VOD content, it isdesired that this content is played in a synchronized manner in alldevices of the users. Synchronization is even more important andsometimes crucial if the users wish also to communicate and shareexperiences and thoughts on the content. It is therefore desired thatthe content is played in a synchronized manner, such that when theyshare their experiences and thoughts on the content, the content that isplayed to each of the users is played at the same time. Otherwise, someusers may comment or act with respect to content that has not yet beenplayed for other users. If the content is live content, then thesynchronization challenge is added to the challenge of playing thecontent as close to the live broadcast as possible.

As users use various types of devices, each having its own capabilities,with different players installed on the devices which use differentprotocols for consuming the content, it is therefore desired tosynchronize between the content that is played on all devices that wishto share a certain content.

GENERAL DESCRIPTION

The synchronized play of content faces many challenges, includingchallenges involved in synchronized play of live shared content, e.g.,to keep the shared playing as close as possible to the time that thelive content is broadcast, through managing the synchronized play, whenconsidering various types of devices and players on the devices thateach of the users that wish to view the content, operate. Otherchallenges which have to be addressed, involve the synchronized play ofcontent when a group of different devices, operated by the same user orseveral users, wish to share the content and data pertaining to thecontent, in a synchronized manner.

While known systems enable to implement synchronization to some extent,these systems do not enable play of the content in multiple devices in amanner that enable the devices to view the content in a fullysynchronized manner, without modification of the content itself,independent of the types of devices, players, and protocols used forviewing the content. In addition, known systems do not enable users toshare experiences and communicate with respect to the shared content,such that they all relate to the same event in the content. Yet,additionally, known systems do not enable users to control sharedcontent such that a synchronized view of the content is maintained.

To illustrate such challenges, assume there is a group of friends whowish to view a live football game. If the group members wish to sharethe same live football game, on different devices, while sharingexperiences on the content, e.g., through a chat, then it is crucialthat they all play the same football game in a fully synchronized, ornearly synchronized, manner. Assume also that the members of the groupuse various types of devices, each having its own capabilities to playthe shared content (processing time, memory, buffering abilities,traffic bandwidth, quality of Internet, or other communicationconnection etc.), and considering various players installed on each userdevice and the protocols used by the devices to obtain the content. Allthese factors influence how and when content is played on each device.If, for example, one member of this group uses a device which isadvanced, and is a newer-generation device than another device used byanother member of the group, the first user having the newer-generationdevice can perform better and keep up with the progress of a contentstreaming, and the device may be able to play the content more closelyto the live broadcast. The older-generation device will, however, lagbehind the live broadcast. The live broadcast of the content to the twodevices, using known systems, will result in low user experience ofcontent sharing between these two devices, as the member of the group,having the more advanced device, may communicate with the others oncontent that has not yet been played on their device, while spoiling theevents in the game to others.

It is therefore desired to be able to play the content in a synchronizedmanner to all users, irrespective of how many devices play the content,which type of device plays the content, whether the content is providedas live or as VOD content, and without modifying the content itself.

According to one aspect of the presently disclosed subject matter thereis provided, in a user's device, a computerized method for facilitatinga synchronized play of content by a user device's player, the methodcomprising:

-   -   receiving a reference position in the content;    -   retrieving a player position in the content; and    -   based on the received reference position and the retrieved        player position:        -   determining if the player position is nearly synchronized            with the reference position; and        -   if in the negative, applying a synchronization process to            reach a calculated sync player position, such that the            player position, when reaching the sync player position, is            nearly synchronized with the reference position.

In addition to the above features, the system according to this aspectof the presently disclosed subject matter can comprise one or more offeatures (i) to (xxiii) listed below, in any desired combination orpermutation which is technically possible:

-   -   (i). wherein receiving the reference position further comprises        calculating a normalized reference position based on the        received reference position, and determining if the player        position is nearly synchronized, based on the calculated        normalized reference position;    -   (ii). wherein receiving the reference position comprises        receiving a content playing state; and applying the        synchronization process based at least on the received content        playing state;    -   (iii). wherein determining if the player position is nearly        synchronized further comprises: calculating a distance between        the reference position and the player position; and determining        that the player position is nearly synchronized when the        distance does not exceed a pre-configured threshold;    -   (iv). wherein applying the synchronization process further        comprises: obtaining capabilities of the player; selecting,        based on the obtained player capabilities, at least one sync        algorithm; and calculating, based on the selected at least one        sync algorithm, the sync player position; and reaching the        calculated sync player position, by applying the selected at        least one sync algorithm;    -   (v). wherein the player capabilities are selected from a group        consisting of: play at speed, frame accurate seek, controlled        buffer size and bandwidth meter, control of average bitrate        (ABR) profiles and control of player buffering sizes or a        combination thereof, and wherein the at least one sync algorithm        is selected from a group comprising: play at speed, seek and        pause, seek to position, or a combination thereof;    -   (vi). wherein the player capabilities comprise play at speed,        and wherein the selected at least one sync algorithm comprises        play at speed, the method further comprising: calculating a        speed matrix comprising at least one degree of speed to apply to        reach a position constituting the sync player position; and        reaching the sync player position by applying the play at speed        algorithm;    -   (vii). wherein calculating the speed matrix is based at least on        one or more of: smooth video playing, time of running in speed        mode, and player learned behavior;    -   (viii). the method further comprising: determining that the        player position is not nearly synchronized with the reference        position, such that the distance between the reference position        and the player position does exceed the pre-configured        threshold, constituting a first threshold, but the distance does        not exceed a pre-configured second threshold, the second        threshold is larger than the first threshold; and applying the        synchronization process by selecting play at speed, to reach the        sync player position.    -   (ix). wherein applying the play at speed algorithm comprises        controlling at least one additional player function to        facilitate an improved play of the content during the reaching        process;    -   (x). wherein controlling the at least one additional player        function comprises controlling a volume of the player;    -   (xi). wherein the player capabilities comprise frame accurate        seek, and wherein the selected at least one sync algorithm        comprises seek and pause, the method further comprising:        calculating a sync player position that exceeds the reference        position; seeking to the calculated sync player position, and        pausing from playing the content;    -   (xii). wherein an attempt includes reaching of the player to a        previously calculated sync player position using selected at        least one sync algorithm, and a result of each attempt includes        either success or failure to reach the sync player position, and        wherein selecting the at least one sync algorithm further        comprises: obtaining a history of attempts and respective        attempts results; selecting the at least one sync algorithm        based at least on the obtained history.    -   (xiii). wherein selecting the at least one sync algorithm        further comprises selecting at least one sync algorithm that is        different than each of sync algorithms used in the history of        attempts;    -   (xiv). wherein the player capabilities comprise frame accurate        seek, and wherein calculating the sync player position further        comprises: executing a seek to position process to calculate the        sync player position; predicting a latency caused by a seek time        required to complete reaching the calculated sync position; and        calculating the sync player position based at least on the        predicted latency;    -   (xv). wherein predicting the latency further comprises:        executing at least one prediction algorithm; and predicting the        latency based on the executed at least one prediction algorithm;    -   (xvi). wherein the at least one prediction algorithm is selected        from a group comprising: bandwidth meter algorithm, average seek        algorithm, and a deep learning algorithm;    -   (xvii). wherein the at least one prediction algorithm is        selected based at least on the player capabilities;    -   (xviii). wherein the at least one prediction algorithm is        selected based at least on computation complexity constraints;    -   (xix). wherein an attempt includes reaching of the player to a        previously calculated sync player position using selected at        least one sync algorithm, and a result of each attempt includes        either success or failure to reach the sync player position,        such that the player position is nearly synchronized with the        reference position, and wherein selecting the at least one sync        algorithm further comprises: obtaining a history of attempts and        respective attempts results; wherein the at least one prediction        algorithm is selected based on at least the obtained history;    -   (xx). the method further comprising: determining that the player        cannot reach any calculated sync player position; transmitting        to a reference server a failure notification;    -   (xxi). the method further comprising: in response to        transmitting the failure notification, receiving an updated        reference position; and applying the synchronization process        with respect to the updated reference position;    -   (xxii). the method further comprising: determining that the        user's device is out-of-sync by determining that the player        position is not nearly synchronized with the reference position;        and repeatedly: obtaining a normalized reference position in the        content; and based at least on the obtained normalized reference        position, applying the synchronization process to reach a        calculated updated sync player position, such that the player        position, when reaching the updated sync player position, is        nearly synchronized with the reference position;    -   (xxiii). wherein the reference position is dynamically        determined by a reference server.

According to another aspect of the presently disclosed subject matterthere is provided a computerized method for facilitating a synchronizedplay of a content by a plurality of user devices joining a virtualshared watch room, wherein a reference position in the content isdetermined by a reference server and wherein each user device of theplurality of user devices performs the facilitating a synchronized playof a content by a user device's player.

According to another aspect of the presently disclosed subject matterthere is provided a computerized system for facilitating a synchronizedplay of content by a user device's player, the system comprising aprocessing and memory circuitry (PMC) configured to:

-   -   receive a reference position in the content;    -   retrieve a player position in the content; and    -   based on the received reference position and the retrieved        player position:        -   determine if the player position is nearly synchronized with            the reference position; and        -   if in the negative, apply a synchronization process to reach            a calculated sync player position, such that the player            position, when reaching the sync player position, is nearly            synchronized with the reference position.

According to another aspect of the presently disclosed subject matterthere is provided a non-transitory computer readable storage mediumtangibly embodying a program of instructions that, when executed by acomputer, cause the computer to perform a method for facilitating asynchronized play of content by a user device's player, the methodcomprising:

-   -   receiving a reference position in the content;    -   retrieving a player position in the content; and    -   based on the received reference position and the retrieved        player position:        -   determining if the player position is nearly synchronized            with the reference position; and        -   if in the negative, applying a synchronization process to            reach a calculated sync player position, such that the            player position, when reaching the sync player position, is            nearly synchronized with the reference position.

The system and the non-transitory computer readable storage mediumdisclosed in accordance with the aspects of the presently disclosedsubject matter detailed above can optionally comprise one or more offeatures (i) to (xxiii) listed above with respect to the method, mutatismutandis, in any technically possible combination or permutation.

According to another aspect of the presently disclosed subject matterthere is provided a content sharing system for facilitating asynchronized play of content by players of a plurality of user devices,the content sharing system, comprising:

-   -   a reference server configured to manage a virtual shared watch        room and to determine a reference position in the content; and    -   a plurality of user devices, wherein each of the user devices is        configured to:        -   receive the reference position in the content;        -   retrieve a player position in the content; and        -   based on the received reference position and the retrieved            player position:        -   determine if the player position is nearly synchronized with            the reference position; and        -   if in the negative, apply a synchronization process to reach            a calculated sync player position, such that the player            position, when reaching the sync player position, is nearly            synchronized with the reference position.

According to another aspect of the presently disclosed subject matterthere is provided a computerized method for facilitating a synchronizedplay of content by players in at least two user devices, the methodcomprising:

-   -   by a processor of a reference server:        -   setting an initial reference position in the content in a            virtual shared watch room;        -   receiving at least two requests from the at least two user            devices to join the virtual shared watch room;        -   sending to each of the user devices a respective reference            position in the content, the reference position being based            at least on the initial reference position, thereby            facilitating each of user devices to apply a synchronization            process to reach a respective player position such that each            player position is nearly synchronized with the reference            position.

In addition to the above features, and to features (i) to (xxiii), themethod according to this aspect of the presently disclosed subjectmatter can comprise one or more of features (a) to (j) listed below, inany desired combination or permutation which is technically possible:

-   -   a) wherein the virtual shared watch room is a dynamic shared        watch room such that devices can join and leave the room at        different times;    -   b) wherein the requests from different user devices of the at        least two devices are received at different times;    -   c) wherein setting the initial reference position is based at        least on a manifest type of the played content;    -   d) wherein setting the initial reference position is based at        least on one protocol used by the players of the user device to        play the content;    -   e) wherein setting the initial reference position is based at        least on one platform used by the user device;    -   f) the method further comprising, repeatedly: updating the        reference position in the content; and sending to the at least        two user devices the updated reference position;    -   g) wherein updating the reference position is in response to        receiving a failure notification from a user device of the at        least two user devices, the failure notification being        indicative that the player position in the user device is not        nearly synchronized with the reference position;    -   h) wherein updating the reference position is in response to a        manifest timeline change;    -   i) wherein updating the reference position is in response to        receiving a request from at least one user device to update the        reference position, the method further comprising: receiving a        request from a user device of the at least one user device to        update the reference position; and determining whether to grant        the request; and updating the reference position if the request        is granted;    -   j) wherein a manifest type of the played content is VOD or live,        wherein determining whether to grant the request is dependent on        the manifest type of played content.

According to another aspect of the presently disclosed subject matterthere is provided a computerized system for facilitating a synchronizedplay of content by players in at least two user devices, the systemcomprising a processing and memory circuitry (PMC) configured to:

-   -   set an initial reference position in the content in a virtual        shared watch room;    -   receive at least two requests from the at least two user devices        to join the virtual shared watch room;    -   send to each of the user devices a respective reference position        in the content, the reference position being based at least on        the initial reference position, thereby facilitating each of        user devices to apply a synchronization process to reach a        respective player position, such that each player position is        nearly synchronized with the reference position.

According to another aspect of the presently disclosed subject matterthere is provided a non-transitory computer readable storage mediumtangibly embodying a program of instructions that, when executed by acomputer, cause the computer to perform a computerized method forfacilitating a synchronized play of content by players in at least twouser devices, the method comprising:

-   -   setting an initial reference position in the content in a        virtual shared watch room;    -   receiving at least two requests from the at least two user        devices to join the virtual shared watch room;    -   sending to each of the user devices a respective reference        position in the content, the reference position being based at        least on the initial reference position, thereby facilitating        each of user devices to apply a synchronization process to reach        a respective player position, such that each player position is        nearly synchronized with the reference position.

The system and the non-transitory computer readable storage mediumdisclosed in accordance with the aspects of the presently disclosedsubject matter detailed above can optionally comprise one or more offeatures (a) to (j) listed above with respect to the method, mutatismutandis, in any technically possible combination or permutation.

According to another aspect of the presently disclosed subject matterthere is provided a computerized method for predicting a latency of aplayer to execute frame accurate seek in a video, the method comprising:

-   -   executing at least one prediction algorithm selected from a        group consisting of: bandwidth meter algorithm, average seek        algorithm, and a deep learning algorithm; and    -   predicting the latency based on the executed at least one        prediction algorithm.

The method according to this aspect of the presently disclosed subjectmatter can further comprise the following feature: wherein the at theleast one prediction algorithm is selected based at least on one of:player capabilities, computation complexity constraints, and history ofattempts.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the invention and to see how it can be carriedout in practice, embodiments will be described, by way of non-limitingexamples, with reference to the accompanying drawings, in which:

FIG. 1 illustrates a generalized diagram of a computerized contentsharing environment 100 in accordance with certain embodiments of thecurrently presented subject matter;

FIG. 2 illustrates a functional block diagram of the reference server140 in accordance with certain embodiments of the presently disclosedsubject matter;

FIG. 3 illustrates a functional block diagram of the user device 150 inaccordance with certain embodiments of the presently disclosed subjectmatter;

FIG. 4 illustrates an exemplary architecture of components inenvironment 100 in accordance with certain embodiments of the presentlydisclosed subject matter;

FIG. 5 illustrates a generalized flow chart of operations performed inuser device 150 in accordance with certain embodiments of the presentlydisclosed subject matter;

FIG. 6 illustrates a functional block diagram of the media synchronizermodule 344 in accordance with certain embodiments of the presentlydisclosed subject matter;

FIG. 6A illustrates an example of a timeline of content in accordancewith certain embodiments of the presently disclosed subject matter;

FIG. 7 illustrates a flow chart of operations comprised in applying thesynchronization process, in accordance with certain embodiments of thepresently disclosed subject matter;

FIG. 8 illustrates a flow chart of operations comprised in applying aplay at speed algorithm, in accordance with certain embodiments of thepresently disclosed subject matter;

FIG. 9 illustrates a flow chart of operations comprised in predictingthe latency, in accordance with certain embodiments of the presentlydisclosed subject matter;

FIG. 10 illustrates an exemplary flow of executing predictionalgorithms, according to certain embodiments of the presently disclosedsubject matter;

FIG. 11 illustrates a generalized flow chart of further operationsperformed in user device 150 in accordance with certain embodiments ofthe presently disclosed subject matter;

FIG. 12 illustrates an example of flow of operations in accordance withcertain embodiments of the presently disclosed subject matter; and

FIG. 13 illustrates a generalized flow chart of operations performed inreference server 140 in accordance with certain embodiments of thepresently disclosed subject matter.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of the invention.However, it will be understood by those skilled in the art that thepresently disclosed subject matter may be practiced without thesespecific details. In other instances, well-known methods, procedures,components and circuits have not been described in detail so as not toobscure the presently disclosed subject matter.

Unless specifically stated otherwise, as apparent from the followingdiscussions, it is appreciated that throughout the specificationdiscussions utilizing terms such as “processing”, “facilitating”,“receiving”, “retrieving”, “determining”, “applying”, “calculating”,“obtaining”, “selecting”, “reaching”, “executing”, “predicting”,“transmitting”, “setting”, “sending”, “updating”, “pausing”, “seeking”,“sending”, or the like, refer to the action(s) and/or process(es) of acomputer that manipulate and/or transform data into other data, saiddata represented as physical, such as electronic, quantities and/or saiddata representing the physical objects. The term “computer” should beexpansively construed to cover any kind of hardware-based electronicdevice with data processing capabilities including a personal computer,a server, a computing system, a communication device, a processor, orprocessing unit (e.g. digital signal processor (DSP), a microcontroller,a microprocessor, a field programmable gate array (FPGA), an applicationspecific integrated circuit (ASIC), etc.), and any other electroniccomputing device, including, by way of non-limiting example,computerized systems or devices such as a reference server 140, a userdevice 150, and a service provider 130, PMC 210, and PMC 320 or SDK 320disclosed in the present application.

The terms “non-transitory memory” and “non-transitory storage medium”used herein should be expansively construed to cover any volatile ornon-volatile computer memory suitable to the presently disclosed subjectmatter.

The operations in accordance with the teachings herein may be performedby a computer specially constructed for the desired purposes, or by ageneral-purpose computer specially configured for the desired purpose bya computer program stored in a non-transitory computer-readable storagemedium.

Embodiments of the presently disclosed subject matter are not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the presently disclosed subject matter asdescribed herein.

As used herein, the phrase “for example,” “such as”, “for instance” andvariants thereof, describe non-limiting embodiments of the presentlydisclosed subject matter. Reference in the specification to “one case”,“some cases”, “other cases”, or variants thereof, means that aparticular feature, structure or characteristic described in connectionwith the embodiment(s) is included in at least one embodiment of thepresently disclosed subject matter. Thus, the appearance of the phrase“one case”, “some cases”, “other cases” or variants thereof does notnecessarily refer to the same embodiment(s).

Usage of conditional language, such as “may”, “might”, or variantsthereof, should be construed as conveying that one or more examples ofthe subject matter may include, while one or more other examples of thesubject matter may not necessarily include, certain methods, procedures,components and features. Thus, such conditional language is notgenerally intended to imply that a particular described method,procedure, component or circuit is necessarily included in all examplesof the subject matter. Moreover, the usage of non-conditional languagedoes not necessarily imply that a particular described method,procedure, component, or circuit, is necessarily included in allexamples of the subject matter.

It is appreciated that certain features of the presently disclosedsubject matter, which are, for clarity, described in the context ofseparate embodiments, may also be provided in combination in a singleembodiment. Conversely, various features of the presently disclosedsubject matter, which are, for brevity, described in the context of asingle embodiment, may also be provided separately or in any suitablesub-combination.

In order to enable a synchronized play of content, according to certainembodiments of the presently disclosed subject matter, a virtual sharedwatch room is established. The virtual shared watch room can enable awatch party of one or more user devices. In the virtual shared watchroom, a room position (also referred to herein and below as “a referenceposition”) is determined, e.g., by an external device, to that of theuser device that wishes to play the shared content. The room position orreference position indicates a position of a reference server in aspecific content at a specific time, with reference to a shared commonclock. The clock can be synced by other external devices. For example,the position in a specific content can include a content frame, or aposition which refers to start of the content (e.g., the start of the TVshow, the movie, the song, the sports game). The specific time, withreference to a shared common clock, can be time according to an absoluteclock, e.g. UNIX time, server's wall clock to which external devices cansync to, by implementing any other known methods for syncing between twodevices. In some cases, the reference server can determine a referenceposition, and can send the determined reference position to otherdevices in order that they can sync. Based on the received referenceposition, including indication of the synced clock, external devicescan, at any point, normalize the received reference position anddetermine the current room position. For example, a reference positionreceived by the devices can be position 0 seconds in the specificfootball game content at time 8:00:00 pm absolute time (e.g., accordingto the UTC clock), meaning the room position was position ‘0’ seconds inthe content, indicative of frame ‘0’ in the content at time 8:00:00 UTC.Within 10 minutes, the devices can calculate that the current referenceposition is “600,000 milliseconds (msec), at 08:10:00 UTC”.

The room position, which is a single position for that established room,can be referenced by other devices that wish to join the room and playthe content, in a manner that the devices can sync to the single roomposition within a pre-configured allowed latency. While referencing theroom position, each of the devices can apply a synchronization processto facilitate the synchronized play of the content on the user device.The synchronized process can be different in each device, and can bedetermined based on various factors that are involved, including thecontent itself, the manifest of the content, or the protocol forobtaining the content of the type of the installed player and itscapability, and previous learning attempts of the device to sync to aroom. Establishing a room in a virtual environment, and setting a roomposition, such that each device can join and sync to the room and theroom position, is advantageous, since synchronization can be achievedirrespective of the types and capabilities of the devices used byvarious users to play the shared content. Also, the synchronizationprocess applied in one device is not related to the synchronizationprocess applied in another device, yet, eventually, all devices aresynchronized between themselves by synchronizing to the room position.Furthermore, since the synchronization process of one device is notrelated to another device, each device can apply the most suitablesynchronization process which is the most efficient process for thatparticular device. Overall, synchronizing to room position improves userexperience in playing a shared content by multiple separate devices in asynchronized manner.

As explained further below, another advantage of the synchronizationprocess to a room, is the avoidance of interfering or modifying thecontent itself, thus being able to perform the synchronization processover any available content, provided in generic over the top (OTT)average bitrate (ABR) protocols.

During participation in the watch room, a user device can continuouslymonitor its synchronization to the room position, and apply thesynchronization process every time the user device determines that it isout-of-sync. Also, the synchronization process can repeatedly be applieduntil reaching a synchronization with the room.

The single room position, which determines for all other devices how andwhen the content should be played, facilitates the synchronized playingof the content, as each user device needs to synchronize to a singlereference position, to achieve a synchronized play among all devices.The room operator can be a reference server that establishes and managesthe room, its position in the content, and the devices that joined theroom. The reference server can dynamically change the room position toprovide the shared content in a manner that optimizes user experience.For example, the reference server can update the room position inresponse to one of the users that wishes to change the position in thecontent that is played to all devices, or if one of the devices isunable to be synced to the room. The update of the room position entailsthe other user devices, which were synced with the room up until thattime, to apply once again the synchronization process, to be synced tothe updated room position.

It should be noted that while throughout the description, the watchparty includes a shared play of content, it should not be regarded aslimiting, and those skilled in the art will appreciate that playing acontent, according to certain embodiments of the presently disclosedsubject matter, can refer to any consumption of a shared content,including the delivery and/or display/presentation of content on acomputerized device.

Bearing the above in mind, reference is made to FIG. 1 illustrating ageneralized diagram of a computerized content sharing environment 100,in accordance with certain embodiments of the currently presentedsubject matter. The environment 100 aims to facilitate a synchronizedplay of content on a user device by virtually establishing a virtualshared watch room.

The environment 100 comprises several components which operativelycommunicate with each other. Environment 100 comprises a virtualestablished room 110, associated with a content 120 which is shared inthe room 110. For example, the shared content 120 of the room 110 can bea football game. Room 110 can be a shared virtual environment, asestablished in known systems, e.g., using a standard API forestablishment of a room/creation of a channel. The room 110 can maintaina room position. The room position (reference position) can be sent todevices. In some cases, the reference position can be determined by anexternal device and can be updated. As explained, the reference positionindicates a reference server in a specific content at a specific time,with reference to a shared common clock, or a clock which can be syncedto by external devices so they can sync to. In some examples, the sharedclock and time can be synced to using Network Time Protocol (NTP). Areference position can include a room position comprising a contentframe, a position in reference to start of the content (e.g. the startof the TV show, the movie, the song, the sports game), with reference tothe absolute time (e.g., Absolute UNIX time). As illustrated above, thereference position can be position 0 seconds in the specific footballgame content at time 8:00:00 pm UTC clock. The absolute time can bereferenced by external devices, such as user devices 150. In someexamples, the user devices 150 participating in the watch party andwhich join the room 110, are synced to this shared absolute time, withina tolerance of e.g., a few 10s of msec, e.g., within 1-2 frames ofcontent. It should be noted that the room 110 does not necessarily playthe content 120. Instead, the room 110 can be associated with sharedcontent 120, while the reference position is indicative of the positionof the room 110 in the content 120, i.e., the point in the content 130that would have been played at a specific time, should the content havebeen played at the room 110.

In some cases, a user 160 that wishes to play a shared content 120 onone or more of his devices, can join the room 110, e.g., by a userdevice 150 joining the room 110. User device 150 can be any computerizeddevice having a memory and processing capabilities, communicationcapabilities, and a player capable of playing content 120, e.g., amobile device such as a smartphone, tablet or laptop computer,television (TV) etc. The user device 150 can comprise an appfacilitating shared consumption of a content. For example, the app hasuser interface screens such as “choose a TV show to watch”, “invitefriends to watch with me”, “chat/message with my friends during theviewing” etc. Pressing the links in the app can result in user device150 joining established room 110. The content 120 to be shared in theroom can be a content created by an over the top (OTT) source also to bereferred to as service provider 130 comprised in environment 100. Forexample, the content 120 can be a sports game, a movie, TV show, or anaudio content. The content can be obtained by user device 150 e.g., bysubscribing to a channel dedicated for a specific content 120 whenjoining the room 110.

The room 110 can be managed by an engagement cloud, also to be referredto as a reference server 140 comprised in environment 100. Referenceserver 140 can be any computerized device having a memory, processingcapabilities and communication capabilities. Reference server 140 can beconfigured to manage the room 110, including managing the referenceposition of the room 110 and communicating with user devices 150 thatjoin the room 110.

With reference to environment 100, in some cases, in order to facilitatea synchronized play of content 120, e.g., a live football game, by theuser device 150, a dedicated room 110 is established. The room 110 isassociated with the football game content. Reference server 140 isconfigured to set an initial reference position in the football game,such as position 0 seconds at time 8:00:00 pm, absolute time (e.g., UTCtime), which is identical to the time that the live broadcast of thefootball game begins. A group of friends, representing users 160, wishto watch the football game together, each with his user device 150.Hence, each of the friends, using their own user device 150, requestsroom 110 to join, e.g., using a dedicated app on user device 150. Therequest to join the room 110 can be sent to reference server 140 whichcan grant the request. Once granted, reference server 140 is configuredto send to each user device 150 the reference position of the room 110,e.g. position 0 seconds in the football game at 8:00:00 pm, UTC. Eachuser device 150 can further obtain the shared content 120, the footballgame, e.g., by subscribing to a channel in room 110 or by obtaining itfrom the service provider 130 using a dedicated content sharing app.Once the football game or a part thereof (e.g., if the football game islive) or data indicative of the football game is received/obtained bythe player in user device 150, user device 150 further retrieves theplayer position in the received football game. Based on the receivedreference position and the retrieved player position, the user device150 determines whether the player position is nearly synchronized withthe reference position. For example, the user device 150 can calculate adistance between the reference position and the player position, anddetermines whether the user device meets a threshold distance. Thethreshold distance can be a parameter which indicates the maximumdistance in time which the user device 150, when participating in awatch room party in room 110, should have from the reference positionset by room 110. If the user device 150 determines that player positionis not nearly synchronized with the reference position, e.g., since thedistance exceeds the pre-configured threshold, then user device 150 canapply a synchronization process. The purpose of the synchronizationprocess is to reach a position in the content 120 such that the playerposition and the reference position are nearly synchronized, e.g., thatthe distance between the positions does not exceed the pre-configureddistance threshold. In order to do so, the player can reach a positionin the content, where the player estimates that, at that position, theplayer position will be nearly synchronized with the room position.Therefore, the player can calculate a sync player position that it canreach, such that the player position, when reaching the sync playerposition, will be nearly synchronized with the reference position.Further details of how to calculate a sync player position are detailedbelow with respect to FIGS. 7-9 .

Reference is now made to FIG. 2 illustrating a high-level functionalblock diagram of the reference server 140, in accordance with certainembodiments of the presently disclosed subject matter. The illustratedreference server 140 includes a processor and memory circuitry (PMC) 210comprising a processor 220 and a memory 230. Reference server 140further comprises a communication interface 240 enabling referenceserver 140 to operatively communicate with external devices, such asuser devices 150 and service provider 130. The processor 220 isconfigured to execute several functional modules in accordance withcomputer-readable instructions implemented on a non-transitorycomputer-readable storage medium. Such functional modules are referredto hereinafter as comprised in the processor 220. The processor 220 cancomprise shared content channel 250 and shared content manager 260.Shared content channel 250 can be a backend microservice that isconfigured to manage the room 110, the room position, and facilitatesynchronization between the user devices 150 that joined the room 110.Shared content channel 250 comprises channel API module 252, positionmanager module 254, and room policy module 256. Channel interface 252can be an API layer that is configured to operatively communicate withboth the user devices 150 and additional backend services such asposition manager module 254 and room policy module 256. Position managermodule 254 is configured to manage the room position including settingthe room position, e.g., based on different inputs such as sharedcontent creation, various manifest types (VOD or live), manifest DVRwindow, VOD duration, capabilities of user devices 150 that joined theroom 110, user position control, such as the ability of the user toinfluence the room position, and content monitoring. When setting a newreference position for room 110, or when updating the referenceposition, position manager module 254 can send the updated referenceposition to user device 150 e.g., using the channel interface 252, suchthat the player can receive an updated reference position to refer to.Room policy module 256 is configured to determine whether a specificevent occurred in environment 100 should trigger re-calculating thereference position to accommodate the event. This may occur, forexample, if user device 150 is not able to sync to the room position110, e.g., since the play is too close to the live broadcast. The userdevice 150 can trigger an event of out-of-sync. The event iscommunicated to room policy module 256. In such a case, room policymodule 256 can determine to update the room position to be further backfrom live, or to determine that this user device 150 remainsout-of-sync.

Shared content manager 260, also comprised in processor 220, can be abackend microservice configured for analyzing and monitoring one or moreshared contents 120 currently used in one or more rooms 110. Sharedcontent manager 260 comprises content analyzer module 262 and contentmonitor module 264. Content analyzer module 262 is configured to analyzenew content 120, identify average bitrate (ABR) protocol (such as HLS orDASH), identify manifest type (such as VOD or live), and create contentmetadata required by the shared content channel 250 (such as segmentlist and protocol conversion formula). Data generated or analysis bycontent analyzer module 262 can be used e.g., by position manage module254, to set a reference position, or to update it. Content monitormodule 264 is configured to continuously monitor the shared content 120and identify changes, such as timeline change, that will be required toupdate the shared content channel 250 and position manage module 254.

PMC 210 further includes memory 230. Memory 230 may store datapertaining to one or more rooms 110 that were established. Each room 110may be associated with one or more content 120 shared in that room 110,and may include data indicative of the content 120 (not shown) such ascontent state (pause e.g. when speed is ‘0’/play (play at normal speedor at a different scale), manifest type etc. Room 110 can also includedata indicative of one or more user devices 232, such as the user device150, that joined the room 110 or is trying to join the room 110.

Reference is now made to FIG. 3 illustrating a high-level functionalblock of user device 150, in accordance with certain embodiments of thepresently disclosed subject matter. The illustrated user device 150includes a processor and memory circuitry (PMC user device) 310comprising a processor 311 and a memory 312. Memory 312 can store dataindicative of one or more rooms 313 to which the user device 150 joinedor is trying to join, such as one or more rooms 110 established byreference server 140. Each room 313 can be associated with the sharedcontent 314 of the room, room position 315, and state of content 316 bythe reference (e.g., pause/play). In some examples, data indicative ofcontent 314, room position 315, and content state 316, can be receivedfrom reference server 140. Memory 312 may further comprise a history ofattempts 317 storing previous attempts of the player 360 to reachsynchronization, either in the current room 313, or general learnsattempts in previous synchronization attempts. The history 317 isfurther described below.

User device 150 may further comprise additional standard components of acomputerized device for ordinary usage of a user, such as components ofa standard user smart device. User device 150 may comprise softwaredevelopment kit (SDK) 320 and a player 360. The player 360 can be astandard player installed in a user device, and can be of various types,according to the type of the user device 150, such as ExoPlayer onAndroid, AVPlayer on iOS and tvOs and HLS,js on HTML5. SDK 320 cancomprise player interface 330 and shared content feature 340. Theprocessor 311 is configured to execute functional modules of SDK 320,such as comprised in player interface 330 and shared content feature340, in accordance with computer-readable instructions implemented on anon-transitory computer-readable storage medium. Such functional modulesare referred to hereinafter as comprised in the processor 320 or in theSDK 320.

Player interface 330 is configured to provide the SDK 320 with access tothe underlying designated player 360. Player interface 330 can be aninterface implemented for various types of players (ExoPlayer, AVPlayer,HLS.JS). Player interface 330 can comprise player capabilities module332, player control module 334, player metrics module 336, and playerevents module 338.

Player capabilities module 332 is configured to expose optional player360 capabilities, such as:

-   -   Frame accurate seek, as known in the art;    -   Play at speed, including the capability of speeding up or        slowing down the original speed of audio or video content;    -   Controlled buffer size (how much time the player is buffering        before starting to play);    -   Bandwidth meter including player estimation for available        bandwidth.

Player control module 334 is configured to expose control functions ofthe player 360, such as:

-   -   Play    -   Pause    -   Seek

Player metrics module 336 is configured to expose player metrics. Playermetrics include at least:

-   -   Current position    -   Current download bandwidth    -   Current Bitrate played    -   Start play buffer size

Player events module 338 is configured to expose registration to playerevents. Player events module 338 can trigger player events to anysubscribed event listener. The events can include for example:

-   -   Player state (buffering, ready)    -   re-buffering event    -   Stream state (playing, speed, BOS, EOS)

Shared content feature 340 is configured to provide the SDK 320 withclient side of shared content synchronization functionality. Sharedcontent feature 340 comprises backend integrator module 342, mediasynchronizer module 344, clock synchronization module 348, player eventlistener module 350, and current room module 352. Backend integratormodule 342 is configured to call backend APIS and listen to backendevents, and, in some examples, update room 313 (including e.g. receivedata which pertains to subscription to shared content channel, setposition of device, room position changed, play state changed).

Media synchronizer module 344 is configured to create thesynchronization algorithm sequence, control the synchronization flow,and monitor synchronization status. Further details of mediasynchronizer module 344 are described with reference to FIG. 6 . Clocksynchronization module 348 is configured to synchronize the SDK wallclock with the reference clock, e.g. using NTP protocol. Player eventlistener module 350 is configured to subscribe to player events, andprovide information to both media synchronizer module 344, required forits operation and accuracy. Current room module 352 is configured toobtain, e.g., from reference server 140, data pertaining to a currentroom that the user device 150 has joined, or is trying to join. The dataobtained can be stored in room 313.

Reference is now made to FIG. 4 illustrating an exemplary architecture400 of components of reference server 140 and user device 150 inenvironment 100, and communication between these components, inaccordance with certain embodiments of the presently disclosed subjectmatter. In some cases, room 110 is established at the cloud, andposition manager module 254 is configured to manage the room 110 fromthe reference server 140 end. Position manager module 254 can interfacewith the SDK 320 running on the user device 150, e.g. through the APIplayer comprising channel interface 252 on the reference server 140 end,and a backend integrator module 342 (backend APIS) at the user device150 end. After user device 150 joins the room 110, position managermodule 254 can send and receive information to and from user device 150pertaining to the room 110 including e.g., sending to the user device150 the reference position, and updating user device 150 when thereference position has changed, and receive from the user device 150when the user device 150 has joined the room 110. Media synchronizermodule 344 can interface with the room 110, e.g. through the channelinterface 252, with the assistance of current room module 352, to obtainthe room position and content state (e.g. pause/play) and can interfacewith the player 360 through player interface 330 to obtain playerposition, state and capabilities.

Referring to FIG. 5 , there is illustrated a generalized flow chart ofoperations performed in user device 150 in accordance with certainembodiments of the presently disclosed subject matter. The followingflowchart operations are described with reference to elements of userdevice 150 and reference server 140. However, this is by no meansbinding, and the operations can be performed by elements other thanthose described herein. Also, reference is made to FIG. 6 illustrating afunctional block diagram of the media synchronizer module 344 in SDK 320in accordance with certain embodiments of the presently disclosedsubject matter. The description of the operations in FIG. 5 areinterchangeably described with reference to elements of mediasynchronizer module 344. Media synchronizer module 344 comprisessynchronization watchdog module 610, synchronization orchestrator module620, speed calculator module 630, seek position calculator module 640,and seek predictor 650. Details of these components are describedfurther below.

With reference to the illustrated example of a group of friends thatwish to view the football game, it is desired that the game is played onthe devices of the friends in a synchronized manner. In order tofacilitate the synchronized play of game, a room 110 can be established,where the room 110 is associated with the content 120 being the footballgame. Reference server 140, e.g., using position manger module 254, canset the initial reference position, such that a user device 150 thatwishes to join the room and play the game in a synchronized manner, cansync to the set reference position. Reference server 140 can receive arequest from a user device 150 to join the room 110 and can send thereference position to the user device 150.

User device 150 can send a request from reference server 140 to join awatch party, by joining room 110, and can receive the reference positionset by the reference server 140. Media synchronizer module 344,comprised in the user device 150, can continuously run while the userdevice 150 participates in the watch party. Whenever media synchronizermodule 344 detects that the player 360 of the user device 150 isout-of-sync with the position of the room 110, media synchronizer module344 starts to execute the synchronization sequence. In some examples,media synchronizer module 344 can execute the synchronization sequencewhen first receiving the reference position when joining the room 110.Alternatively, or additionally, media synchronizer module 344 cancontinuously run while the user device 150 participates in the watchparty, and execute the synchronization sequence whenever it detects thatthe player 360 is out-of-sync with the room position.

With reference to FIG. 6 , in some cases, synchronization watchdogmodule 610 is configured to verify that the player is synchronized tothe room 110, and, optionally, trigger the synchronization process, e.g.with the assistance of the synchronization orchestrator module 620, whensynchronization watchdog module 610 detects that the player it isout-of-sync with the room position. In some examples, synchronizationwatchdog module 610 may be activated once the user device 150 joins theroom and, optionally, subscribes to a channel e.g. a channel dedicatedto a specific content 120, e.g. through communicating with sharedcontent channel 250 in the room 110. Synchronization watchdog module 610is configured to communicate with current room module 352 to receivedata pertaining to the room 110.

In order to facilitate a synchronized play of content 120 by a userdevice's player 360, media synchronizer module 344, e.g. by watchdogmodule 610, can receive a reference position in the content 120 (block510 in FIG. 5 ), e.g. from current room module 352 which may obtain thedata pertaining to a current room 110 from the reference server 140. Insome examples, the watchdog module 610 obtains the data when the userdevice 150 initially joins the room 110. Alternatively or additionally,the watchdog module 610 may be triggered periodically to read thecurrent room position and state from the current room module 352 inorder to monitor whether the player 360 is nearly synchronized orout-of-sync with the room position.

In some examples, the received reference position includes dataindicative of the reference position in the content 120 at a certainidentified time e.g., absolute time, or server clock to which the userdevice is synced to.

Based on the received reference position, watchdog module 610 cannormalize the received reference position to calculate a current roomposition (block 511). For example, if the reference position includesdata indicative that at 8:00:00 the room position was set to 0 msec atcontent 120 and state is play in speed 1, then in case the user device150 joins the room at 8:00:05, the normalized position, e.g. the currentroom position, would be the position in the reference plus the timepassed, meaning 5000 msec at 8:00:05. If the play state is paused (asexplained below), the current room position would be 0 msec at 8:00:05.It is to be noted that the normalized reference position is indicativeof the current room position, sometimes, based on the state of thecontent (play/pause). Calculating the normalized reference position isadvantageous, since external user device 150 can calculate the currentroom position, irrespective of when the initial reference position wasdetermined, sent or received at the user device by the reference server140 or normalized by them. As explained further below, in some examples,if the user device 150 does not reach synchronization with the referenceposition after applying a synchronization process, then the user deviceis able to re-calculate the normalized room position, irrespective ofhow much time has lapsed, since it was sent from the reference server.

Determining whether the player 360 is nearly synchronized with thereference position can be based on the calculated current referenceposition, the normalized reference position.

In some examples, receiving the reference position comprises receiving acontent playing state (block 512). The content playing state can bee.g., pause, play, or speed play. The content playing state may beindicative of the state of the content in the room 110, e.g. whether thereference position is progressing along the content (e.g. is progressingin the frames of the content), or whether the content is paused at theroom 110. Receiving the content playing state can assist watchdog module610 to determine a current reference position. For example, the currentreference position, calculated when the content playing state is paused,is different from the current reference position calculated when thecontent playing state is speed play. If it is determined that the player360 is out-of-sync, then the synchronization process can be appliedbased at least on the received content playing state. Further details onhow to apply the synchronization process, based on the received contentplaying state, are described further below.

If the user device 150 has just joined a room 110 and subscribed to achannel, user device 150 may further obtain e.g., by subscribing to thechannel and receiving from the service provider 130, the content 120 toplay (block 513). The content 120 may be the shared content associatedwith the room 110. Once the content 120 is received and is played/loadedto the player 360, watchdog module 610 may retrieve a player 360position in the content (block 520). For example, with reference to FIG.6 , player metrics module 336 can expose the player 360 metricsincluding at least the current position of the player in the content,the current download bandwidth, the current bitrate played, and thestart play buffer size. Based upon at least some of the data obtained byplayer metrics module 336, such as the current player position and thestate (play/pause), watchdog module 610 can determine whether the playerposition is nearly synchronized with the reference position (block 530).In some examples, in order to determine whether the player position isnearly synchronized with the reference position, watchdog module 610 cancalculate a distance between the reference position and the playerposition (block 352). If the calculated distance does not exceed apre-configured threshold, then the watchdog module 610 can determinethat the player position is nearly synchronized with the referenceposition. For the sake of clarity, the term “nearly synchronized” may beused herein to imply the possibility of an allowed tolerance in theposition of the player in the device and position of the room. Theallowed tolerance ensures that each user, when playing the content onits user device, will hear and see the same events in the content, e.g.,a goal in the game, at sufficiently close points in time, such that itwill not be discernible that they did not experience the goal atdifferent times. This allowed tolerance is bound by a pre-configuredthreshold, where the threshold is small enough to keep synchronized playof the content according to the room position, while being tolerant tosome latency between the two systems, the room 110, and the user device150. The pre-configuration of the threshold is advantageous, since if aplurality of user devices 140 join room 110, and each of the userdevices 150 is nearly-synchronized with the room 110, such that thedistance between the player position of each of the user devices 150 andthe room position does not exceed a pre-configured threshold, thisentails that all user devices 140 in the room 110 are nearlysynchronized with each other.

In some examples, the pre-configured threshold can be [−50,50] msec,such that the distance between the player position and the normalizedreference position is within the range of [−50,50] msec. The distancecan be calculated by subtracting the position in the content of theplayer from the position in the content of the normalized referenceposition. To illustrate this, consider an example where the referenceposition is 10000 msec at 8:00:00 at play speed 1. At current time of8:00:05, the normalized position is 15000 msec. A valid player positionsuch that is nearly synchronized with the reference position within theallowed threshold, should be within the range of [14950,15050].

If watchdog module 610 determines in the negative, i.e., that the playerposition is not nearly synchronized with the reference position, then,with reference to FIG. 6 , it may trigger synchronization orchestratormodule 620 to apply a synchronization process (block 540 in FIG. 5 ). Insome examples, the desired result of applying the synchronizationprocess is to reach, at a future time, a calculated sync playerposition. In some examples, the term a ‘sync player position’ shouldrefer to a calculated estimated position of the content, such that whenreached by the player 360 after applying a sync algorithm, the playerposition will be nearly synchronized with the reference position.

The user device 150 aims to play the content 120 by the player 360, in anearly synchronized manner to that indicated by the room 110 in thereference position. If the player 360 is not synchronized, the userdevice 150 aims to move the player to a position in the content where itwill be synchronized with the reference position. As such, the userdevice 150 may select one or more sync algorithms to apply. Based on theselected sync algorithm, to calculate a sync player position and toreach the sync player position (block 550). Further details of applyinga synchronization process (block 540) appear below with reference toFIG. 7 .

Once the player 360 reaches the sync player position, watchdog module610 can determine whether the player position is now nearly synchronizedwith the reference position. There may be several reasons for the player360 to remain out-of-sync, despite the selection of a sync algorithm toapply, calculating the sync player position, and reaching the calculatedsync player position. For example, failure can occur in reaching thesync player position e.g., if the sync algorithm did not work asexpected, and the player 360 did not reach the calculated sync playerposition, or if the player 360 did reach the calculated sync playerposition, yet the reference position made further progress, and thecurrent player position is not nearly synchronized with the referenceposition. Other examples of being out-of-sync can include using seekestimation based on bandwidth meter (BW meter) when the network is veryunstable, such that estimation of buffering time is inaccurate, suchthat calculated sync player position is inaccurate. In case watchdogmodule 610 determines that the player position is not nearlysynchronized with the reference position, the synchronizationorchestrator module 620 can repeatedly apply the synchronizationprocess, until the player position is synchronized with the referenceposition (this is shown by the dashed line in FIG. 5 from block 550 toblock 510). Further details of reaching the calculated sync playerposition are described with reference to FIGS. 7-10 . Also, furtherdetails of repeatedly applying the synchronization process appear below.

Reference is made to FIG. 6A illustrating an example 610 of a timelineof content, with reference position as received as indicated in 611, theplayer position and calculated normalized reference position asindicated in 612, and sync player position as indicated in 613. Toillustrate the example above, the reference position received by theuser device 150 includes a reference position of 0 msec at 8:00:00:000while play speed is 1. The user device 150 can normalize the receivedreference position to determine the current room position, and reach anormalized room position of 5000 at time 8:00:05:000. The current playerposition in the content is 6000 at time 8:00:05:000. Based on thesepositions, and assuming it takes the player 500 msec to seek to aparticular position in the content, a sync algorithm can be determined,and a sync player position can be calculated to be 5500 at 8:00:05:500.It is assumed that the reference position will also be 5500 at time8:00:05:500, hence the player will be nearly synchronized with thereference position.

As described further below with respect to FIG. 11 , in case it isdetermined that the player position is not nearly synchronized with thereference position after reaching the sync player position,synchronization orchestrator module 620 can apply several syncalgorithms to reach the calculated sync player position.

Reference is now made to FIG. 7 illustrating operations comprised inapplying the synchronization process (block 540 in FIG. 5 ), inaccordance with certain embodiments of the presently disclosed subjectmatter. In some examples, in order to apply the synchronization process,synchronization orchestrator module 620 may select, from severalavailable sync algorithms, which sync algorithm is optimal for reachingsynchronization. In order to select, synchronization orchestrator module620 may first obtain capabilities of the player 360 (block 710), e.g.using player interface 330 and player capabilities module 332. Playercapabilities module 332 is configured to expose optional playercapabilities of player 360 to synchronization orchestrator module 620,such as play at speed, frame accurate seek, controlled buffer size andbandwidth meter, control of average bitrate (ABR) profiles and controlof player buffering sizes, or a combination thereof. Each capability ofthe player 360 capabilities may assist the synchronization orchestratormodule 620 to reach a sync player position. The player capabilities arefurther described below. Player control module 334 is configured toexpose control functions of player 360 to synchronization orchestratormodule 620, such as: Play, Pause and Seek.

Based on the obtained player capabilities, the player position and thereference position, synchronization orchestrator module 620 may select async algorithm to apply (block 720). In some examples, synchronizationorchestrator module 620 selects more than one sync algorithm to apply,optionally, to be applied in a sequential manner. In some examples, thesync algorithms are selected from a group consisting of: ‘play atspeed’, ‘seek and pause’, ‘seek to position’, or a combination thereof.

Once the sync algorithm is selected, synchronization orchestrator module620 can calculate a sync player position (block 730). It should be notedthat the sync player position should refer to a calculated estimatedposition of the reference of the content, such that when reached by theplayer 360 after applying a sync algorithm, the player position will benearly synchronized with the reference position. It should be noted thatthe sync player position is indicative of an estimated position that thereference server will reach in the content, at a certain time. Thereference position itself is not changed or influenced by thecalculation.

The sync player position can be calculated based on the selected syncalgorithm. As exemplified above with respect to reference position being300 msec at time 8:00:00 and the player position being 150 msec at time8:00:00, assuming that the player capability includes play at speed, thesync player position could be calculated to be at position 450 msec at8:01:50, where the player play at speed ×2 for 150 msec.

Based on the calculated sync player position, the player can reach thecalculated sync player position, by applying the selected at least onesync algorithm (block 740 corresponding block 550 in FIG. 5 ). Althoughapplying the synchronization process has been described as if it occursonly if the player position is determined to be not nearly synchronizedwith the reference position, a person versed in the art would realizethat applying the synchronization process can occur at all times afterobtaining the reference position and player position. In examples wherethe player position is determined to be nearly synchronized with thereference position, then applying the synchronization process andreaching the calculated sync player position can include continue playat regular speed.

The first sync algorithm is ‘play at speed’. Reference is made to FIG. 8illustrating operations comprised in applying the play at speedalgorithm, in accordance with certain embodiments of the presentlydisclosed subject matter. The operations can be performed when applyingthe synchronization process (block 540 in FIG. 5 ) when ‘play at speed’is selected.

In some examples, if the obtain player capabilities (block 710)comprises ‘play at speed’, synchronization orchestrator module 620 canselect the ‘play at speed’ sync algorithm to be applied (block 810).This stage corresponds to block 720 of FIG. 7 . In some examples, ‘playat speed’ includes the player 360 playing the content at a certainspeed: high speed at different degrees, slow speed, or regular speed, inorder to reach the sync player position. In order to apply a ‘play atspeed’ sync algorithm, a speed matrix can be calculated (block 820).With reference to FIG. 6 , synchronization orchestrator module 620 cancommunicate with speed calculator module 630. Speed calculator module630 is configured to calculate the speed matrix that will most optimallytake the player 630 to a player position within the allowedpre-configured threshold from the reference position. In some examples,the speed matrix comprises a degree of speed to apply to reach thecalculated sync player position. In the above example of thepre-configured threshold of [−50,50] msec, where the normalizedreference position is 300 msec and the player position is 150 msec,speed calculator module 630 can calculate the following speed matrix:

-   -   play in speed ×2 for 150 msec.

After 150 msec, the room position will be 450 msec and the playerposition will be 450 msec.

In some examples, the speed matrix comprises more than one degree ofspeed to apply. For example, if the distance is 1.5 seconds behindreference position, calculator module 630 can calculate the followingspeed matrix:

-   -   run 1250 msec in 1.8 speed; then    -   run 900 msec in 1.5 speed; then    -   run 500 msec in 1.1 speed

In some examples, the speed calculator module 630 can calculate thespeed matrix that will most optimally take the player to a positionwithin the allowed threshold from the room position. When calculating,the speed calculator module 630 may base the calculation on one or moreparameters to achieve the optimal matrix in terms of:

-   -   User experience    -   Time of running in speed mode    -   Player learned behavior (e.g., how immediate/fast the player 630        actually changes its speed)

While basing the calculation on the above parameters, and based on thereference position and the player position, the speed calculator module630 may dynamically determine the matrix that best achieves a balancebetween the above parameters. For example, bad user experience can bereflected in ping pong forward and rewind, if missing the allowedthreshold, or too long time in forward mode. To achieve a balancebetween the parameters, speed calculator module 630 may apply one ormore rules on the speed such as ‘sync time may be capped by 5 sec, withminimal time in high speed’.

In some examples, speed calculator module 630 calculates the speedmatrix that reflects the best balance between time to sync (TTS) anduser experience in terms of viewing experience. In some examples, speedcalculator module 630 may keep TTS less than 1 second and low speedsplaying, as much as possible. Since speed calculator module 630 maycalculate the speed matrix player learned behavior, then a differentspeed matrix may be calculated for different types of players.

Following is a description of exemplary algorithms for calculating thespeed matrix. In some examples, a second threshold can be defined. Inthe defined second threshold, play at speed is allowed. For example, ifthe allowed sync threshold (the initial allowed first threshold) is[−50,50], the second threshold can be [−1500,1500], such that inside therange of the first threshold the player is synced. Out of the secondthreshold too far, seek based algorithm (another sync algorithmdescribed further below) can be selected, whereas inside the secondthreshold, play at speed sync algorithm is applied. For each interval, amatrix that defines the speed is determined. For example: <100 run in1.1, 100<=x<500 1.5 500<x 1.8. Yet, in some examples, configuration anddevice specific parameters such as speed accuracy of the player, andallowed time to get to sync position, can be added to the fixedintervals when calculating the speed matrix. Yet, further in someexamples, the interval configuration can be used as a starting point.Then, a learning process can be implemented while making adjustments tothe configuration (AI), until maximizing results to criteria isachieved. The matrix calculation can also take into account the rangesize of the sync threshold, so if the allowed threshold is [−50,50], thealgorithm would look for reaching the threshold at a very low speed, asto avoid overshooting and going out of the boundary on the other side.If, for example, the allowed threshold is [−500,500], then the algorithmhas more room for mistakes, so it can use higher speed.

Once the speed matrix is calculated, synchronization orchestrator module620 can reach the calculated sync player position (block 740 in FIG. 4 )by applying the ‘play at speed’ algorithm (block 830). In some examples,when applying the ‘playing at speed’ algorithm, the speed calculatormodule 630, or its executer, can further control at least one additionalplayer function (block 840) e.g., to facilitate an improved userexperience by an improved play of the content during the reachingprocess. For example, calculator module 630 can control the volume ofthe player, to achieve a better user experience when running at speed,or can provide a notification to the application that a sync algorithmis applied, such that the application can determine to display a‘syncing’ slide until reaching the calculated sync player position, andrevert to displaying the video only when reaching the calculated syncplayer position.

In some cases where the obtained player capabilities include ‘play atspeed’, before selecting and applying the ‘play at speed’ algorithm,synchronization orchestrator module 620 can determine that the distancebetween the reference position and the player position meet a certaincondition, such that the ‘play at speed’ algorithm would be the optimalalgorithm to reach synchronization. As described above, synchronizationorchestrator module 620 can determine that the distance is within asecond threshold, e.g. [400,100] msec, which is larger than the initialpre-configured threshold of e.g. [−50,50] msec for determining that theplayer position is not nearly synchronized with the reference position.Yet, based on the distance being within the second threshold,synchronization orchestrator module 620 can determine that the optimalalgorithm to reach synchronization is to apply the play at speedalgorithm. Based on that determination, synchronization orchestratormodule 620 can select the play at speed algorithm in such cases.Therefore, synchronization orchestrator module 620 can determine thatthe distance exceeds a first threshold being the pre-configuredthreshold for determining that the player position is not nearlysynchronized with the reference position, but does not exceed apre-configured second threshold, where the second threshold is largerthan the first threshold, and to select the ‘play at speed’ algorithm toreach the sync player position.

In some cases, as explained above, even after calculating a sync playerposition and applying a synchronization process, the player 360 isout-of-sync with the room 110, for example, since the sync algorithm didnot work as expected and the player 360 did not reach the calculatedsync layer position, or if the player 360 did reach the calculated synclayer position, yet the reference position made further progress, andthe current player position is not nearly synchronized with thereference position. Such an attempt to reach synchronization, andfailure to reach the synchronization, can be used to learn the playerperformance in that particular synchronization process, i.e. withrespect to the current content and room, or, on a more general level,with respect to the player performance when applying a certain syncalgorithm.

Hence, in some cases, when synchronization orchestrator module 620selects a synchronization process to be applied, synchronizationorchestrator module 620 may base the selection on history of previousattempts of the player 360 to sync. Considering the history of previousattempts may be advantageous in order reach the calculated sync playerposition in an optimal manner. For example, if a sync algorithm wasselected and applied several times, yet the player 360 did not succeedin reaching the calculated sync player position, then this syncalgorithm should not be selected at this stage.

In some examples, an attempt can include previous attempts of player 360to reach a previously calculated sync player position. The previousattempts to reach the calculated sync player position were made usingone or more sync algorithms that were selected. The previous attemptswere made in the current synchronization process session, while tryingto reach a calculated sync player position in the current room 110, orin previous synchronization processes sessions, unrelated to the currentroom 110, and are indicative of general performance and success of syncalgorithms.

Each attempt resulted in an outcome, either success or failure to reachthe sync player position. In some examples, optionally after the playerdid not manage to sync to the room 110, synchronization orchestratormodule 620 may determine to apply a synchronization process to result ina calculated sync player position which does not meet the pre-configuredthreshold, yet meets another, second, pre-configured, threshold whichreflects a farther distance from the reference position than the firstthreshold, yet is closer than the current player position, andconstitutes some progress in the synchronization process. In suchexamples, the failure of reaching the sync player position can occur ifa certain selected sync algorithm also resulted in not reaching thesecond pre-configured threshold.

The attempts and respective results can be stored in memory 312, in userdevice 150, in history of attempts 317. In some examples, history ofattempts 317 can constantly be updated, e.g. each time a sync algorithmis applied, by sending feedback on the selected and applied syncalgorithm to history of attempts 317, or at the end of a session ofattempts, comprising feedback on the overall result of the syncalgorithms that were selected in the session.

In order to make a selection of the sync algorithm, synchronizationorchestrator module 620 may obtain the history of attempts andrespective attempts results, and select the sync algorithm based atleast on the obtained history. For example, synchronization orchestratormodule 620 may determine, based on the history of attempts that pertainattempts made in the current synchronization process, that a certainsync algorithm does not succeed in reaching the first or secondthresholds, and after one or several attempts to use the specific syncalgorithm, it should not be selected at this stage. In such examples,synchronization orchestrator module 620 may select a sync algorithm thatis different to each of sync algorithms used in the history of attempts.Alternatively, or additionally, synchronization orchestrator module 620may determine, based on the general history of the synchronizationprocess, that a certain sync algorithm does not succeed in similar casesof trying to synchronize, e.g. since the player 360 does not act asexpected in such sync algorithms, resulting in failures. Hence,synchronization orchestrator module 620 may skip the specific syncalgorithm when selecting a sync algorithm from available syncalgorithms.

Below is a description of sync algorithms including ‘seek’ functionalityof the player 360, such as ‘seek to position’ and ‘seek and pause’. The‘seek to position’ sync algorithm includes seeking a sync playerposition, such that the player position, when reaching the sync playerposition, is nearly synchronized with the reference position, andreaching that player position. The ‘seek and pause’ sync algorithmincludes the seeking to a sync player position, which exceeds thereference position, reaching that position, and pausing from playing thecontent. Pause proceeds until the reference position reaches that syncplayer position. ‘Seek and pause’ may be used in cases where the playercannot reach a sync player position e.g., since the content is live, thebuffering limit of the player 360 is low, and the calculated sync playerposition is too close to live streaming, such that the player 360 cannotplay the content at any close sync player position. In such cases, theplayer can jump to a later position in the content, and wait for thereference position to reach the player position. Also, ‘seek and pause’can be used in cases where the player position is not within the second,larger, threshold, the player capability of frame accurate seek is notenabled, or, in other cases, after multiple failures of seek toposition.

In some cases, in order to calculate the sync player position after a‘seek to position’ algorithm is selected, media synchronizer module 344calculates the required sync player position involving seeking to aposition, e.g., the player position that player should seek to in orderto synchronize with the reference position. In some examples, thecalculated sync player position includes a prediction of the time thatwill be required by the player 360 to reach a calculated sync playerposition when seeking is executed. For example, assume the normalizedreference position at 8:00:00 is 1000 and the player position is 3000.The player 360 needs to seek to position 1000 now at 8:00:00, however,according to the buffering time estimation, to seek to position 1000, itwill take the player 500 msec until start to play, so if ‘seek’ isactivated, when start to play from position 1000, the normalizedposition at time 8:00:0 will be already 1500. In such a case, the syncplayer position should be 1500.

Predicting the time to seek may be crucial for success of the player 360to reach synchronization with the room 110. In some examples, thelatency caused by the time required for the player 360 to perform theaction of seeking and reaching the sync player position makes the syncplayer position no longer relevant, since the reference position alreadyprogressed in a manner which rendered the positions being no longersynchronized.

Reference is made to FIG. 9 illustrating operations comprised incalculating the sync player position (block 730 in FIG. 7 ), inaccordance with certain embodiments of the presently disclosed subjectmatter. Reference is also made to FIG. 6 with respect to mediasynchronizer module 344 components.

In some cases, synchronization orchestrator module 620 may request seekposition calculator module 640 to execute a ‘seek to position’ processto calculate a player position that player should seek (block 910). Theseek position calculator module 640 may calculate the position to seekto based on one or more of the following parameters:

-   -   Capabilities of player 360 (such as frame accurate seek)    -   Player position, distance between player and normalized        reference positions    -   Player buffer time    -   For example, if it is determined that the player buffer is 3        seconds, the player position is 1000 and reference position is        2000, it can be determined that the frames to seek are already        in the device player buffer, so it is not required to pull from        the network the frames to seek, resulting in a faster seek    -   Previous attempts result, e.g., as obtained from history of        attempts 317        Seek position calculator module 640 may apply one or more rules        to calculate position to seek. Following are some non-limiting        examples of execution of the seek position calculator module        640:    -   If the player has already made several previous attempts, e.g. 5        attempts, in the current session, to reach a sync player        position, and failed to reach a sync player position that is        nearly synchronized with the reference position, seek position        calculator module 640 may apply a ‘seek and pause’ algorithm by        calculating a sync player position including a position that is        ahead of the reference position, and pausing until the reference        position catches up.    -   If capabilities of player 360 comprise ‘speed play’ but not        ‘frame accurate seek’, and the current player position is 100        msec from a segment start position, seek position calculator        module 640 may seek a segment start position, and then execute a        ‘play at speed’ sync algorithm for reaching the room position.

In some cases, synchronization orchestrator module 620 may furtherpredict a latency caused by a seek time required to complete reachingthe calculated sync position (block 920). For example, synchronizationorchestrator module 620 may request seek predictor 650 to calculate aprediction of the maximum latency that will be required for seeking agiven position. Based on the predicted latency, synchronizationorchestrator module 620 calculates the sync player position.

In some examples, seek predictor 650 is configured to execute one ormore prediction algorithms to estimate seek-to-play time to provide aprediction (block 930). The prediction algorithms are selected from agroup consisting of: bandwidth meter algorithm, average seek algorithm,and deep learning algorithm. Selecting a prediction algorithm can bebased on one or more parameters, including at least player capabilities,computation complexity constraints, history of attempts, or acombination thereof.

Following is a description of the prediction algorithms:

Bandwidth Meter Algorithm

This prediction algorithm can be used, e.g., if the player capabilitiesinclude, inter alia:

-   -   Player reliable required buffered time to start play.

The player should expose:

-   -   1. Play buffering time—the time needed to be buffered, that,        when reached the player, the player can start playing the first        frame in the buffer    -   2. Current ABR bitrate playing    -   3. BW estimation    -   Bandwidth meter exposed by the player 360 to estimate the        bandwidth at the current moment    -   Access to the metadata about current played bitrate, e.g., as        obtained from player metrics module 336;

Bandwidth meter algorithm may input the above capabilities into aformula to anticipate buffering time latency:

Latency=<time to buffer>*<current bitrate><current bandwidth>

Average Seek Time Algorithm

This prediction algorithm may require obtaining player state events,e.g., by obtaining them from the player interface 330 using playerevents module 338. The player state events can be “READY” or“BUFFERING”. The prediction algorithm may calculate moving average ofprevious seek attempts in history, on a configured window, excludingseeks that resulted in greater than a defined threshold deviation in theresult distance from the requested position. For example, in the last 5minutes, player had 3 seeks which took 400, 500, and 600 msecsrespectively. For the same bitrate, seek time will be estimated to bethe average—500 msec.

Deep-Learning Algorithm

The deep learning prediction algorithm may have more accuracyprediction, however it may require higher consumption of deviceresources. This algorithm aims to provide an outcome of accurate latencyprediction based on ever-growing training data history, e.g., such thatit is created from previous seek attempts. The deep learning algorithmmay use the training data to build its ever-improving prediction forseek time for a specific user device. The process will start with one ofthe above algorithms to build the data set, and, at some point in timewhen the training data is sufficiently large, it may start using thedeep learning prediction. The used training data may include, amongothers: seek distance from current position (in or out of existingbuffer), device condition (CPU load, memory load), network condition(network condition, current available bandwidth), other SDK bandwidthconsuming features, time of day, played bitrate, content type, and seeksuccess (how far from the spot the player hits).

In some examples, seek predictor 650 may select a prediction algorithmbased on the SDK 320 configuration and player 360 capabilities. Yet, insome examples, seek predictor 650 may select a prediction algorithmwhile balancing between accuracy and complexity. For example, if theuser device 150 cannot run ML, then the prediction algorithm will haveless accurate prediction, but less complexity. Yet, since the predictionalgorithm and the number of sync actions taken during thesynchronization proceed are, in overall, not frequent in the operationof the user device 150, the required computational complexity can haveless effect on the decision whether to select the deep learningprediction algorithm or not. Still further, seek predictor 650 mayexecute the prediction algorithms according to the exemplaryprioritization flow illustrated in FIG. 10 according to certainembodiments of the presently disclosed subject matter:

-   -   1. The Media Synchronizer module 344, using synchronization        orchestrator module 620, may request a latency prediction for a        seek position from the seek predictor 650 (block 1010);    -   2. If Deep-Learning prediction algorithm is enabled (block        1020):        -   Execute Deep Learning algorithm (block 1030);    -   3. Else, if player capabilities expose the set of capabilities        required for BW        -   Meter prediction algorithm (block 1040):            -   Execute Bandwidth (BW) Meter algorithm (block 1050);        -   Else:            -   Execute average seek time algorithm (block 1060);    -   4. Seek latency prediction may be returned to synchronization        orchestrator module 620 (block 1070);    -   5. After the seek has been executed (block 1080) the        synchronization orchestrator module 620 may send prediction        accuracy feedback to the seek predictor 650 that is fed back        into the executed algorithm for learning or for history tracking        (block 1090).

Another option of execution can include moving from the BW meteralgorithm to the average seek time algorithm, in case, after multipleattempts, it is identified that the BW meter does not provide goodresults.

In some cases, despite several attempts to sync to the referenceposition, e.g., by reaching several sync player positions anddetermining that the player position is not nearly synchronized with thereference position, the media synchronizer module 344 may determine thatthe player 360 cannot reach any calculated sync player position, andhence cannot sync to the reference position. There may be severalreasons for not being able to sync to the reference position. Forexample, if the reference position in the content is too close to thelive broadcast, and the player 360 cannot comply with the bandwidthrequirements. Assume, for illustration, that the reference server 140set the reference position to 3 seconds behind live, and player's 360limitation is to buffer 5 seconds before play. In such an example,player 360 can never reach synchronization with the reference position,irrespective of which sync algorithm is to be selected. Another examplecan be based on the player capabilities and history of attempts, whereafter obtaining the history and considering current player capabilities,it is determined that the player cannot sync.

Reference is made to FIG. 11 illustrating a generalized flow chart offurther operations performed in user device 150 in accordance withcertain embodiments of the presently disclosed subject matter. Oncedetermining that the player position is not nearly synchronized with thereference position (block 530 in FIG. 5 ), the synchronization processcan be applied. Based on one or more reasons exemplified above, mediasynchronizer module 344 may determine, during the synchronizationprocess, that the player 360 cannot reach any calculated sync playerposition (block 1110).

Based on the reason that the player cannot reach synchronization, mediasynchronizer module 344 may transmit a failure notification, e.g., toreference server 140 (block 1120). Transmitting to the reference servera failure notification may be advantageous if the reference serverwishes to update the reference position, such that user devices 1410which wish to join the shared room 110 can reach synchronization.Transmitting the failure notification may be dependent on the reason fornot being able to synchronize. For example, if the reason for not beingable to sync results from the reference server 140 setting a referenceposition which cannot be reached by the player 340, then the mediasynchronizer module 344 may transmit a failure notification. On theother hand, if the player 360 cannot reach synchronization since theaccuracy of the prediction algorithm executed by the user device 150 islow, then there is no point in notifying the reference server 140, andmedia synchronizer module 344 may avoid notifying the reference server140 of its failures.

In response to receiving the failure notification, the reference server140 may dynamically update the reference position and may send theupdated reference position to the user device 150 that is in the room110 (block 1130). The user device 150 can then apply the synchronizationprocess 1140 with respect to the updated reference position (block1140).

Referring back to FIG. 5 , in some cases, the user device 150, e.g.,using synchronization watchdog module 610, can continuously monitor thesynchronization of the player position to that of the reference positionduring the watch party when the content is played. If thesynchronization watchdog module 610 determines that the user's device isout-of-sync by determining that the player position is not nearlysynchronized with the reference position, the synchronizationorchestrator module 620 may apply the synchronization process to achievesynchronization. Following are non-limiting examples of reasons that theplayer position is out-of-sync with the reference position: the userdevice 150 has just joined a room 110; the user device 150 is in theroom 110 and a room participant changed the reference position or playstate of the content in the room 110 (controlling the reference positionby a device is further described below); the user device 150 wassynchronized with the room 100 and lost synchronization (for exampleafter a re-buffering event of the user device 150); the reference server150 identified timeline change in the content and updated the referenceposition for all user devices 140 in the room 110; the user device 150notified the reference server that it cannot sync to the referenceposition and the reference server 140 updated the reference position toaccommodate it.

In some examples, the synchronization process can be applied,repeatedly, until the player position is synchronized with the referenceposition (this is shown by the dashed line in FIG. 5 from block 550 toblock 510). In order to repeatedly apply the synchronization process,synchronization orchestrator module 620 may obtain a current referenceposition in the content, e.g. receiving a current reference positionfrom the reference server 150 and calculating a normalized referenceposition, or calculating the normalized reference position based on theinitially received reference position and the current time. Based atleast on the normalized reference position, the synchronization processcan be applied to reach a calculated updated sync player position, suchthat the player position, when reaching the updated sync playerposition, is nearly synchronized with the reference position.

Reference is made to FIG. 12 illustrating an example of flow ofoperations in accordance with certain embodiments of the presentlydisclosed subject matter:

As illustrated, the flow initiated by the synchronization watchdogmodule 610 is periodically executed and runs the synchronizerorchestrator module 620 to execute the following stages:

-   -   1. Obtain reference position, e.g., from the room module 352        (1101). In some examples, content state can also be obtained;    -   2. Obtain player position, e.g., from the player interface 330        (1102). In some examples, player state (play/pause) can also be        obtained;    -   3. Send feedback to last algorithm executed on execution result        accuracy (1103) (for the algorithms to apply tuning, if needed)    -   4. If the player position is in sync with the reference        position, processing is done (1104)    -   5. If the room was paused (such as when an update is received        from the reference server of a change in the content state from        play to pause), then change player state from play to pause        (1105), or seek to position (1106) and pause in position if        needed (1107)    -   6. Get the player capabilities (1108)    -   7. If the player is within the predefined threshold (e.g.,        second threshold) (1109), player position can be tuned using        e.g., speed play. In such cases, player capabilities are        determined to make sure ‘play at speed’ capability is available        in the player (1110), update e.g. in history of attempts 317,        that ‘last algorithm used was speed’ (1111) then calculate speed        matrix (1112) and loop back to start (arrow to 1101).    -   8. If not:        -   1. Calculate seek position (1114) and calculate and add the            estimated seek latency (1115)        -   2. Based on the output of the position calculator, it can be            determined whether to apply seek to accurate position (‘seek            to position’, 1116), or seek ahead of room time and pause            (‘seek and pause’, 1118)        -   3. Execute seek (1117) or seek and pause (1119) and state            change (if needed) and loop back to start (arrows to 1101)

Reference is now made to a description of the reference server 140managing and operating a room 110 to which one or more devices can join.In some cases, the reference server 140 may facilitate a synchronizedplay of a content by a plurality of user devices 140 joining a virtualshared watch room. The reference server can determine the referenceposition, and each user device 150 that wishes to join the room mayperform the operations described above with reference to FIG. 5 , untilreaching synchronization with the room.

Reference is made to FIG. 13 illustrating a generalized flow chart ofoperations performed in reference server 140 in accordance with certainembodiments of the presently disclosed subject matter.

As explained above, in some cases, reference server 140 may establish ashared watch room to facilitate a synchronized play of content byplayers in user devices 150 that wish to join the room. In order tofacilitate the synchronized play, the reference server 140, e.g., usingposition manager module 254, illustrated in FIG. 2 , may set an initialreference position in the content in the virtual shared watch room thatit established (block 1310). Position manager module 254 may receiverequests from a plurality of user devices 150 to join the virtual sharedwatch room (block 1320). In some examples, the position manager module254 may receive one request from a user device 150. Yet, in someexamples, the position manager module 254 may receive at least tworequests from at least two user devices 150. In order to facilitate thesynchronized play of content by players in user devices 150, positionmanager module 254, e.g., using channel interface 252, may send to eachuser device 150 a respective reference position (block 1330). Thereference position sent to each of the user devices 150 is based atleast on the initial reference position. It should be noted that therespective reference position sent to each user device 150 should beinterpreted as identical in terms of the indication of the referenceposition in the content 120, yet, the reference position may be sentfrom the reference server 140 and received by the user device 150 atdifferent times. In some examples where more than one manifest type isinvolved, the reference position can have different values in theposition field (but not in the time field). In such cases, the referenceserver 140 can calculate the room position for one or more manifesttypes (such as HLS or DASH), and determine the time of the referenceposition to be 8:00:00 for both, where the position for HLS is 1000 andfor DASH can be 2000. The reference server 140 can calculate a list ofpositions for all content URLs and send the map of URL to positions tothe user devices joining the shared content channel. Each user device150 receiving the map can select, based on the URL that the user device150 plays, the corresponding position, and sync the player to thatposition.

Once the user device 150 has received the reference position, the userdevice 150 can apply the synchronization process, as detailed above, toreach a respective player position, such that each player position isnearly synchronized with the reference position.

In some examples, the virtual shared watch room 110 established by thereference server 140 is a dynamic shared watch room, such that devicescan join and leave the room at different times. Each of the user devices150 can join at a different time, receive the reference position, andsync to the room, and leave the room at a later stage. As such, therequests from different user devices 150 are received at differenttimes.

The position manager module 254 can set the initial reference positionwhen first establishing the room 110. Additionally, the position managermodule 254 can set the initial or an updated reference position,randomly or based on one or more parameters. For example, setting theinitial reference position can be based at least on a manifest type ofthe played content, e.g., live/VOD. For example, if the manifest is VOD,the manifest can start from position 0 and is a closed manifest, suchthat all segments of the content are in possession of the referenceserver 140, and any network delays in routing segments between theservice provider and the reference server/the user devices of thecontent are irrelevant. In such cases, the position manager module 254can determine to set the position to 0. If, however, the manifest islive, then it is an open manifest, such that segments of the contentkeep being added and removed at the reference server 140, whilefollowing absolute epoch time to identify segment position. This mayaffect the reference server 140 when setting a reference position. Forexample, in ‘live’ the reference server 140 may set reference positionas close as possible to the live content, yet the reference positionshould be such that it can be reached by most of the user devices 140that have joined the room 110. Another example of a parameter may be theprotocol, or the number of URLs available for the shared content used bythe players of the user device 150 to play the content, such thatsetting the initial reference position is based at least on at least onethe protocols. Different URLs used by the user device 150, such as dashor HLS, may influence the initial reference position. Yet anotherexample of a parameter may be the platform used by the user device 150,such as Android, IOS, or the type of player used by the user device 150,such that setting the initial reference position is based on theplatform/type of player used by the user device 150.

To illustrate, for VOD content the reference server 140 can set bothinitial position and initial state. In some examples, by default, thereference server 140 set the initial position to 0 and initial state toPLAY, however any creator of room 110 can request to set a differentinitial position and state on creation, that will override the defaultconfiguration. For live content, the reference server 140 can calculatea segment table of the live manifest (or manifests, if more than one),with absolute time for each segment, and calculate the timelinedifference between the URLs. Then, the position manager module 254 canselect a position based on configured time from the manifest end(optionally, 15 seconds). When user devices 150 join the room 110, theuser devices 150 can report some requirements (such as minimal buffertime) and the reference server 140, based on policy, can determinewhether the current position does not fit the requirements, and toupdate the room position accordingly, as explained below.

In some cases, the position manager module 254 can update the referenceposition (block 1340), e.g., once room policy module 256 determines thata specific event should trigger re-calculating the reference position toaccommodate the event. For example, if user device 150 is not able tosync to reference position because it is too close to live content, theposition manager module 254 may determine whether to put the referenceposition further back from live, or have this user device 150 remainout-of-sync. Position manager module 254 may update the referenceposition in response to room policy module 256 receiving one or more ofthe following events, and determine that an update of the referenceposition is required: manifest change, type of players of user devices,receiving a failure notification from a user device 150, or receiving arequest from a user device 150 to update the reference position. Forexample, detecting a change to the ABR manifest might impact the sharedcontent synchronization. For example, this may occur in cases where thecontent has more than one URL, and timeline discontinuity, detected inone or more of the servers, will re-calculate the position. Receiving,e.g., from user devices 150, an indication of the capabilities of theirplayers, may also result in updating the reference position, asdifferent players have different capabilities and different ability toreach sync with the room. If a new user device 150 joined the room 110,and the type of player of the new user device cannot meet referenceposition that is 2 sec behind live, since it has a buffering limit thatrequires 5 sec, then room policy module 256 may determine to update thereference position, or may determine that this new device remainsout-of-sync. Also, receiving a failure indication from user device 150indicative that the player position in the user device 150 is not nearlysynchronized with the reference position, may result in updating thereference position. Yet, in some examples, a user wishes to control thecontent being played in the room, and may send a request for thereference server 140 to update the room position. In such examples, roompolicy module 256 can determine whether to grant the request or not. Forexample, room policy module 256 may refuse the request, e.g., if thecontent is live, and the request is to update the position to be furtherback from live. Room policy module 256 may also refuse the request if itdetermines, based on the players of the user devices that are in theroom, that some user devices 150 cannot sync to the requested referenceposition. If the request is granted by the room policy module 256, thenroom policy module 256 can update the reference position and send theupdated reference position to the user devices to sync.

Each of the reasons may trigger an update of the reference position,with the aim that the room policy module 256 aims to set a referenceposition that all, or most of the user devices 150 that joined the room110, can be synced to.

In some examples, updating the reference position can be done in arepetitive manner by position manager module 254. Once the referenceposition is updated, the updated reference position is sent to the userdevices 140 that joined the room (block 1330 can be executed onceagain).

It is noted that the teachings of the presently disclosed subject matterare not bound by the flow charts illustrated in FIGS. 5, 7-13 , and thatthe illustrated operations can occur out of the illustrated order. Forexample, operations 510, 511, 512 and 520, stages in flow 12 pertainingto different sync algorithms, or 1310 and 1320 shown in succession, canbe executed substantially concurrently, or in the reverse order.

It is noted that the teachings of the presently disclosed subject matterare not bound by the computerized content sharing environment 100described with reference to FIG. 1 , by the reference server 140described with reference to FIG. 2 , or by the user device 150 describedwith reference to FIG. 3 . Equivalent and/or modified functionality canbe consolidated or divided in another manner, and can be implemented inany appropriate combination of software with firmware and/or hardwareand executed on a suitable device. The reference server 140 can be astandalone network entity, or integrated, fully or partly, with othernetwork entities. Those skilled in the art will also readily appreciatethat the data repositories such as memory 230 or memory 312 can beconsolidated or divided in other manner; databases can be shared withother systems or be provided by other systems, including third partyequipment.

It is to be understood that the invention is not limited in itsapplication to the details set forth in the description contained hereinor illustrated in the drawings. The invention is capable of otherembodiments and of being practiced and carried out in various ways.Hence, it is to be understood that the phraseology and terminologyemployed herein are for the purpose of description and should not beregarded as limiting. As such, those skilled in the art will appreciatethat the conception upon which this disclosure is based may readily beutilized as a basis for designing other structures, methods, andsystems, for carrying out the several purposes of the presentlydisclosed subject matter.

It will also be understood that the system according to the inventionmay be, at least partly, implemented on a suitably programmed computer.Likewise, the invention contemplates a computer program being readableby a computer for executing the method of the invention. The inventionfurther contemplates a non-transitory computer-readable memory tangiblyembodying a program of instructions executable by the computer forexecuting the method of the invention.

Those skilled in the art will readily appreciate that variousmodifications and changes can be applied to the embodiments of theinvention as hereinbefore described without departing from its scope,defined in and by the appended claims.

1. In a user's device, a computerized method for facilitating asynchronized play of content by a user device's player, the methodcomprising: receiving a reference position in the content; retrieving aplayer position in the content; and based on the received referenceposition and the retrieved player position: determining if the playerposition is nearly synchronized with the reference position; and if inthe negative, applying a synchronization process to reach a calculatedsync player position, such that the player position, when reaching thesync player position, is nearly synchronized with the referenceposition.
 2. The computerized method of claim 1, wherein receiving thereference position further comprises calculating a normalized referenceposition based on the received reference position, and determiningwhether the player position is nearly synchronized, based on thecalculated normalized reference position.
 3. The computerized method ofclaim 1, wherein receiving the reference position comprises receiving acontent playing state; and applying the synchronization process based atleast on the received content playing state.
 4. The computerized methodof claim 1, wherein determining if the player position is nearlysynchronized further comprises: calculating a distance between thereference position and the player position; and determining that theplayer position is nearly synchronized when the distance does not exceeda pre-configured threshold.
 5. The computerized method of claim 4,wherein applying the synchronization process further comprises:obtaining capabilities of the player; selecting, based on the obtainedplayer capabilities, at least one sync algorithm; and calculating, basedon the selected at least one sync algorithm, the sync player position;and reaching the calculated sync player position, by applying theselected at least one sync algorithm.
 6. The computerized method ofclaim 5, wherein the player capabilities are selected from a groupconsisting of: play at speed, frame accurate seek, controlled buffersize and bandwidth meter, control of average bitrate (ABR) profiles andcontrol of player buffering sizes or a combination thereof, and whereinthe at least one sync algorithm is selected from a group comprising:play at speed, seek and pause, seek to position, or a combinationthereof.
 7. The computerized method of claim 5, wherein the playercapabilities comprise play at speed, and wherein the selected at leastone sync algorithm comprises play at speed, the method furthercomprising: calculating a speed matrix comprising at least one degree ofspeed to apply to reach a position constituting the sync playerposition; and reaching the sync player position by applying the play atspeed algorithm.
 8. The computerized method of claim 7, whereincalculating the speed matrix is based at least on one or more of: smoothvideo playing, time of running in speed mode, and player learnedbehavior.
 9. The computerized method of claim 7, the method furthercomprising: determining that the player position is not nearlysynchronized with the reference position, such that the distance betweenthe reference position and the player position does exceed thepre-configured threshold, constituting a first threshold, but thedistance does not exceed a pre-configured second threshold, the secondthreshold being larger than the first threshold; and applying thesynchronization process by selecting play at speed, to reach the syncplayer position.
 10. The computerized method of claim 7, whereinapplying the play at speed algorithm comprises controlling at least oneadditional player function to facilitate an improved play of the contentduring the reaching process.
 11. The computerized method of claim 10,wherein controlling the at least one additional player functioncomprises controlling a volume of the player.
 12. The computerizedmethod of claim 5, wherein the player capabilities comprise frameaccurate seek, and wherein the selected at least one sync algorithmcomprises seek and pause, the method further comprising: calculating async player position that exceeds the reference position; seeking to thecalculated sync player position, and pausing from playing the content.13. The computerized method of claim 5, wherein an attempt includesreaching of the player to a previously calculated sync player positionusing selected at least one sync algorithm, and a result of each attemptincludes either success or failure to reach the sync player position,and wherein selecting the at least one sync algorithm further comprises:obtaining a history of attempts and respective attempts results;selecting the at least one sync algorithm based at least on the obtainedhistory.
 14. The computerized method of claim 13, wherein selecting theat least one sync algorithm further comprises selecting at least onesync algorithm that is different to each of sync algorithms used in thehistory of attempts.
 15. The computerized method of claim 5, wherein theplayer capabilities comprise frame accurate seek, and whereincalculating the sync player position further comprises: executing a seekto position process to calculate the sync player position; predicting alatency caused by a seek time required to complete reaching thecalculated sync position; and calculating the sync player position basedat least on the predicted latency.
 16. The computerized method of claim15, wherein predicting the latency further comprises: executing at leastone prediction algorithm; and predicting the latency based on theexecuted at least one prediction algorithm.
 17. The computerized methodof claim 16, wherein the at least one prediction algorithm is selectedfrom a group comprising: bandwidth meter algorithm, average seekalgorithm, and a deep learning algorithm.
 18. The computerized method ofclaim 17, wherein the at least one prediction algorithm is selectedbased at least on the player capabilities.
 19. The computerized methodof claim 17, wherein the at least one prediction algorithm is selectedbased at least on computation complexity constraints.
 20. Thecomputerized method of claim 17, wherein an attempt includes reaching ofthe player to a previously calculated sync player position usingselected at least one sync algorithm, and a result of each attemptincludes either success or failure to reach the sync player position,such that the player position is nearly synchronized with the referenceposition, and wherein selecting the at least one sync algorithm furthercomprises: obtaining a history of attempts and respective attemptsresults; wherein the at least one prediction algorithm is selected basedon at least the obtained history.
 21. The computerized method of claim1, the method further comprising: determining that the player cannotreach any calculated sync player position; transmitting to a referenceserver a failure notification.
 22. The computerized method of claim 21,the method further comprising: in response to transmitting the failurenotification, receiving an updated reference position; and applying thesynchronization process with respect to the updated reference position.23. The computerized method of claim 1, the method further comprising:determining that the user's device is out-of-sync by determining thatthe player position is not nearly synchronized with the referenceposition; and repeatedly: obtaining a normalized reference position inthe content; and based at least on the obtained normalized referenceposition, applying the synchronization process to reach a calculatedupdated sync player position, such that the player position, whenreaching the updated sync player position, is nearly synchronized withthe reference position.
 24. The computerized method of claim 1, whereinthe reference position is dynamically determined by a reference server.25. A computerized method for facilitating a synchronized play of acontent by a plurality of user devices joining a virtual shared watchroom, wherein a reference position in the content is determined by areference server and wherein each user device of the plurality of userdevices performs the computerized method of claim
 1. 26. A computerizedsystem for facilitating a synchronized play of content by a userdevice's player, the system comprising a processing and memory circuitry(PMC) configured to: receive a reference position in the content;retrieve a player position in the content; and based on the receivedreference position and the retrieved player position: determine if theplayer position is nearly synchronized with the reference position; andif in the negative, apply a synchronization process to reach acalculated sync player position, such that the player position, whenreaching the sync player position, is nearly synchronized with thereference position.
 27. A non-transitory computer readable storagemedium tangibly embodying a program of instructions that, when executedby a computer, cause the computer to perform a method for facilitating asynchronized play of content by a user device's player, the methodcomprising: receiving a reference position in the content; retrieving aplayer position in the content; and based on the received referenceposition and the retrieved player position: determining if the playerposition is nearly synchronized with the reference position; and if inthe negative, applying a synchronization process to reach a calculatedsync player position, such that the player position, when reaching thesync player position, is nearly synchronized with the referenceposition.
 28. A content sharing system for facilitating a synchronizedplay of content by players of a plurality of user devices, the contentsharing system comprising: a reference server configured to manage avirtual shared watch room and to determine a reference position in thecontent; and a plurality of user devices, wherein each of the userdevices is configured to: receive the reference position in the content;retrieve a player position in the content; and based on the receivedreference position and the retrieved player position: determine if theplayer position is nearly synchronized with the reference position; andif in the negative, apply a synchronization process to reach acalculated sync player position, such that the player position, whenreaching the sync player position, is nearly synchronized with thereference position.
 29. A computerized method for facilitating asynchronized play of content by players in at least two user devices,the method comprising: by a processor of a reference server: setting aninitial reference position in the content in a virtual shared watchroom; receiving at least two requests from the at least two user devicesto join the virtual shared watch room; sending to each of the userdevices a respective reference position in the content, the referenceposition being based at least on the initial reference position, therebyfacilitating each of user devices to apply a synchronization process toreach a respective player position, such that each player position isnearly synchronized with the reference position.
 30. The computerizedmethod of claim 29, wherein the virtual shared watch room is a dynamicshared watch room such that devices can join and leave the room atdifferent times.
 31. The computerized method of claim 30, wherein therequests from different user devices of the at least two devices arereceived at different times.
 32. The computerized method of claim 29,wherein setting the initial reference position is based at least on amanifest type of the played content.
 33. The computerized method ofclaim 29, wherein setting the initial reference position is based atleast on one protocol used by the players of the user device to play thecontent.
 34. The computerized method of claim 29, wherein setting theinitial reference position is based at least on one platform used by theuser device.
 35. The computerized method of claim 29, the method furthercomprising: repeatedly: updating the reference position in the content;and sending to the at least two user devices the updated referenceposition.
 36. The computerized method of claim 35, wherein updating thereference position is in response to receiving a failure notificationfrom a user device of the at least two user devices, the failurenotification being indicative that the player position in the userdevice is not nearly synchronized with the reference position.
 37. Thecomputerized method of claim 35, wherein updating the reference positionis in response to a manifest timeline change.
 38. The computerizedmethod of claim 35, wherein updating the reference position is inresponse to receiving a request from at least one user device to updatethe reference position, the method further comprising: receiving arequest from a user device of the at least one user device to update thereference position; and determining whether to grant the request; andupdating the reference position if the request is granted.
 39. Thecomputerized method of claim 38, wherein a manifest type of the playedcontent is VOD or live, wherein determining whether to grant the requestis dependent on the manifest type of played content.
 40. A computerizedsystem for facilitating a synchronized play of content by players in atleast two user devices, the system comprising a processing and memorycircuitry (PMC) configured to: set an initial reference position in thecontent in a virtual shared watch room; receive at least two requestsfrom the at least two user devices to join the virtual shared watchroom; send to each of the user devices a respective reference positionin the content, the reference position being based at least on theinitial reference position, thereby facilitating each of user devices toapply a synchronization process to reach a respective player positionsuch that each player position is nearly synchronized with the referenceposition.
 41. A non-transitory computer readable storage medium tangiblyembodying a program of instructions that, when executed by a computer,cause the computer to perform a computerized method for facilitating asynchronized play of content by players in at least two user devices,the method comprising: setting an initial reference position in thecontent in a virtual shared watch room; receiving at least two requestsfrom the at least two user devices to join the virtual shared watchroom; sending to each of the user devices a respective referenceposition in the content, the reference position being based at least onthe initial reference position, thereby facilitating each of userdevices to apply a synchronization process to reach a respective playerposition, such that each player position is nearly synchronized with thereference position.
 42. A computerized method for predicting a latencyof a player to execute frame accurate seek in a video, the methodcomprising: executing at least one prediction algorithm selected from agroup consisting of: bandwidth meter algorithm, average seek algorithm,and a deep learning algorithm; and predicting the latency based on theexecuted at least one prediction algorithm.
 43. The computerized methodof claim 42, wherein the at the least one prediction algorithm isselected based at least on one of: player capabilities, computationcomplexity constraints, and history of attempts.